feat: set lfs.concurrenttransfers to 100 for mirror clones#270
feat: set lfs.concurrenttransfers to 100 for mirror clones#270joshfriend merged 1 commit intomainfrom
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f6132662b8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // LFS fetches are I/O-bound; the git-lfs default of 8 is too low. | ||
| // See git-lfs/git-lfs#6241 for an upstream change (unreleased) that | ||
| // raises the default to 3×NCPU. | ||
| {"lfs.concurrenttransfers", "100"}, |
There was a problem hiding this comment.
Apply lfs.concurrenttransfers in snapshot clone before fetch
lfs.concurrenttransfers is written in mirrorConfigSettings, but LFS downloads happen in a separate snapshot working clone (withSnapshotClone/cloneForSnapshot in internal/strategy/git/snapshot.go, then git lfs fetch at line 744). A regular git clone does not carry arbitrary repo config keys like lfs.concurrenttransfers into the new clone, so this new setting is not seen by the command that actually performs LFS fetches and the default concurrency remains in effect. In practice this makes the commit’s intended throughput improvement a no-op unless the same config is also set (or passed via -c) on the snapshot clone before git lfs fetch.
Useful? React with 👍 / 👎.
The git-lfs default of 8 concurrent transfers is too low for LFS snapshot generation, which is I/O-bound. This sets it to 100 via the mirror git config to better saturate network bandwidth during
git lfs fetch.See git-lfs/git-lfs#6241 for an upstream change (unreleased) that raises the default to 3xNCPU.